REMARKS 

Claims 1-31 are pending in the application. Claims 14, 19, and 21 have been 
amended to correct informalities. Applicant submits that these amendments do not raise 
any new issues of patentability, and thus respectfully requests their entry. 

35 U.S.C. § 102 and §103 Rejections; 

Claims 1-31 were rejected under 35 U.S.C. § 102(b) as being anticipated by Luke, 
U.S. Patent 6,505,267. Applicant respectfully traverses this rejection. 

With respect to the § 102 rejection, the cited reference fails to teach or suggest 
all of the elements of the independent claims. With respect to the § 103 rejections, the 
prior art references, taken singly or in combination, fail to teach or suggest all of the 
elements of the independent claims. Independent claim 1 recites, in pertinent part: 

"An SMBus message handler comprising: 

a memory configured to store microcode comprising at least two 
programs each for handling a bus command protocol and comprising at 
least one instruction; 

an interface to a register configured to identify a starting address of a 
program in said memory; 

an instruction fetch unit configured to read an instruction at an address in 
said memory , said address being specified by a program counter; and 

a finite-state machine configured to receive and interpret the instructions 
read by said instruction fetch unit and manage the data transfer between an 
SMBus interface and a register set in compliance with said instructions 
read from said memory." (Emphasis added) 



9 



Independent claims 10 and 19 recite similar combinations of features. In the office 
action, the Examiner addressed the arguments from the previous response, finding them 
unpersuasive. Applicant respectfully disagrees with the Examiner's counterarguments. 
Thus, in addition to the reasons stated in the previous office action response, Applicant 
submits that the claims are allowable for the following additional reasons. 

In the previous office action response, the Applicant noted that Luke is directed to 
a Universal Serial Bus (USB) peripheral bridge, while independent claim 1 recites an 
"SMBus message handler." Applicant further argued that USB is an entirely different 
bus than SMBus, and since Luke makes no mention whatsoever of an SMBus. it thus 
fails to anticipate the independent claims . 

In item #5 of the 'Response to Arguments' section, the Examiner contends that 
"[a] preamble is generally not accorded any patentable weight where it merely recites the 
purpose of a processor the intended use of a structure, and where the body of the claim 
does not depend on the preamble for completeness , but instead, the process steps or 
structural limitations are able to stand alone ." (Emphasis added). 

MPEP 21 11.02(1) states: 

Any terminology in the preamble that limits the structure of the claimed 
invention must be treated as a claim limitation . See, e.g., Corning Glass 
Works v. Sumitomo Elec. U.S.A., Inc., 868 F.2d 1251, 1257, 9 USPQ2d 
1962, 1966 (Fed. Cir. 1989). (Emphasis added). 

Applicant submits that the terminology SMBus in the preamble clearly limits the 
structure of each of claims 1,10 and 19 to a message handler of an SMBus , and would 
thus exclude the Universal Serial Bus (USB) to which Luke is directed. The SMBus 
limitation of the structure recited in the preamble is also recited in the body of each of 
the independent claims . For example, the body of claim 1 includes the clause: 
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a finite-state machine configured to receive and interpret the instructions 
read by said instruction fetch unit and manage the data transfer between an 
SMBus interface and a register set in compliance with said instructions 
read from said memory. (Emphasis added). 

Similar clauses are recited in claims 10 and 19. Since the preamble specifies an SMBus, 
while the body of the claim also includes the limitation of data transfer between an 
SMBus interface and a register set, it is clear that the SMBus limitation, has patentable 
weight, as this limitation is recited in both the preamble and the body of the claim. Luke 
makes no mention whatsoever of an SMBus . Thus, Luke clearly fails to teach or 
suggest the limitation of "data transfer between an SMBus interface and a register" 
set as recited in the body of the independent claims , and further fails to teach or 
suggest an SMBus message handler , as recited in the preamble of the independent 
claims. 

In item #2 of the 'Response to Arguments' section, the Examiner contends that 
"once compiled the program stored in the memory is essentially [in the] instruction 
language set for the processor or the controller to execute." However, as is apparent from 
the Wikipedia citation submitted with Applicant's previous response, compiling a high 
level language results in a series of machine instructions. Each machine instruction is in 
turn implemented by a series of microinstructions, which may be called a microprogram 
or microcode, as a microprogram is often referred to. Only in a CPU that uses 
microcode, each machine instruction is in turn implemented by microcode. However, 
nothing in Luke teaches or suggests a CPU that uses microcode, and therefore, Luke 
fails to teach or suggest "a memory configured to store microcode" as recited in 
claim 1, and similarly recited in the other independent claims. 

Even if assuming one would modify Luke to use a microcode-enabled processor, 
the microcode would clearly not be stored in Luke's elements 32 and 40, which Examiner 
reads on Applicant's recited "memory configured to store microcode", as elements 32 
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and 40 represent an external EEPROM and a RAM, respectively. Thus, Luke fails to 
teach or suggest "a memory configured to store microcode." 

Furthermore, Luke provides no teaching or suggestion that registers 66 are 
configured to identify a starting address of a microcode program, and thus does not teach 
or suggest "a register configured to identify a starting address of a program in said 
memory" as recited in claim 1, and similarly recited in the other independent claims. 

With regard to item #4 of the office action, Applicant submits that, in addition to 
the reasons given in the previous office action response, Luke fails to teach a "finite-state 
machine" as recited in the independent claims. As noted above and in the previous office 
action response, Luke fails to provide any teaching or suggestion of an SMBus. 
Accordingly, it follows that Luke fails to teach or suggest " a finite-state machine 
configured to ... manage the data transfer between an SMBus interface and a 
register set" as recited in claim 1 and similarly recited in the other independent 
claim. 

For at least the reasons given above and in the previous office action response, 
Applicant submits that Luke does not teach or suggest all of the elements of the 
independent claims. Accordingly, removal of the § 102 rejection is respectfully 
requested. 

With regard to the § 103(a) rejections, Applicant notes that Luke is the primary 
reference for each. Thus, for at least the reasons stated above as well as in the previous 
office action response, Applicant submits that the cited references, taken singly or in 
combination, fail to teach or suggest all of the elements of the independent claims, as 
none of the secondary references remedy the deficiencies of Luke noted above. 
Accordingly, removal of the 35 U.S.C. § 103(a) rejection is respectfully requested. 
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CONCLUSION 



Applicant submits the application is in condition for allowance, and an early 
notice to that effect is requested. 

If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5500- 
92201/EAH. 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8800 

Date: December 10. 2007 
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